This looks cool! I'll play around with it a bit.

You mean name = "main"? That's peculiar. What happens if there are multiple driver programs under app/?

Sorry, I was not very specific.

I meant that the project name on the fpm.toml (name = "template" if one clones this repository) should match the directory name where the project is contained. If you see the launch.json file one option is

    { "name": "(gdb) Launch main program",
      "type": "cppdbg",
      "request": "launch",
      "program": "${workspaceFolder}/build/vscode/bin/${workspaceFolderBasename}",

That ${workspaceFolderBasename} variable must match the executable file. For the main program, fpm will set that executable name to the name of the project.

The launch file has different options, mainly:

• Launch main program: Speaking strictly, this launchs the executable that matchs the main directory name, ussually the main program.
• Launch this program: This will launch the open file, being a file inside app
• Launch test: This will launch the open test file, works exactly like "Launch this program", but for tests

This is amazing work.

Overall works nicely, locally.

Locally

Managed to build the project with gfortran just fine. For the record:

• CTRL + SHIFT + P (Palette)
• Tasks: Run Task -> fpm install

This installs template, as you pointed out. Trying to debug this fails as it's looking for bin/${workspaceFolderBasename}, which of course doesn't exist.

Replacing "template" with "main", and Run Task again: Installs main as expected.

Now Debugging works as well: Palette -> "Run and Debug"

Some remarks.

• Not sure where Intel comes in. gfortran has been baked in fpm install@tasks.json.
• hardcoding the install directory in build/vscode/bin/ will inevitably trip people up (tripped me). Though it's only a preference, having it in {workspaceFolder}/bin/ might be more straightforward.
• --profile -Og is the "debugging" set of flags and is hardcoded. Neither here or there atm.

HPC/ remote development

This is a big no-no in most cases. I'm both happy and sad that this wouldn't work without significant fiddling around. Some major problems is 1) running tasks on the frontend/login nodes, 2) for Intel finding the oneAPI root isn't easy (even with manually pointing it to it).

it does try to grab gfortran from the PATH and run with it. It failed.

Bottom line: it should fail(?). No running compute tasks on frontend/login nodes, though a few HPC systems let the users compile on those nodes (bad practice though; different architectures say hi!)

Documentation

I've got some idea on how this works. Where should we make a few notes of it though? TOOLING.md? TOOLING and README?